aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/proto
Commit message (Collapse)AuthorAgeFilesLines
* Lock busdma operations and serialize detach against open/closeMarcel Moolenaar2019-07-044-27/+77
| | | | | | | | | | Use sx to allow M_WAITOK allocations (suggested by markj). admbugs: 782 Reviewed by: markj Notes: svn path=/head/; revision=349714
* proto: change device permissions to 0600Ed Maste2018-11-221-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | C Turt reports that the driver is not thread safe and may have exploitable races. Note that the proto device is intended for prototyping and development, and is not for use on production systems. From the man page: SECURITY CONSIDERATIONS Because programs have direct access to the hardware, the proto driver is inherently insecure. It is not advisable to use this driver on a production machine. The proto device is not included in any of FreeBSD's kernel config files (although the module is built). The issues in the proto device still need to be fixed, and the device is inherently (and intentionally) insecure, but it might as well be limited to root only. admbugs: 782 Reported by: C Turt <ecturt@gmail.com> MFC after: 3 days Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=340771
* Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.Justin Hibbits2016-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some architectures, u_long isn't large enough for resource definitions. Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but type `long' is only 32-bit. This extends rman's resources to uintmax_t. With this change, any resource can feasibly be placed anywhere in physical memory (within the constraints of the driver). Why uintmax_t and not something machine dependent, or uint64_t? Though it's possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on 32-bit architectures. 64-bit architectures should have plenty of RAM to absorb the increase on resource sizes if and when this occurs, and the number of resources on memory-constrained systems should be sufficiently small as to not pose a drastic overhead. That being said, uintmax_t was chosen for source clarity. If it's specified as uint64_t, all printf()-like calls would either need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t aren't horrible, but it would also bake into the API for resource_list_print_type() either a hidden assumption that entries get cast to uintmax_t for printing, or these calls would need the PRI*64 macros. Since source code is meant to be read more often than written, I chose the clearest path of simply using uintmax_t. Tested on a PowerPC p5020-based board, which places all device resources in 0xfxxxxxxxx, and has 8GB RAM. Regression tested on qemu-system-i386 Regression tested on qemu-system-mips (malta profile) Tested PAE and devinfo on virtualbox (live CD) Special thanks to bz for his testing on ARM. Reviewed By: bz, jhb (previous) Relnotes: Yes Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D4544 Notes: svn path=/head/; revision=297000
* Check the sync operation.Marcel Moolenaar2015-07-281-1/+6
| | | | Notes: svn path=/head/; revision=285927
* o make sure the boundary is a power of 2, when not zero.Marcel Moolenaar2015-07-261-5/+9
| | | | | | | | | o don't convert 0 to ~0 just so that we can use MIN. ~0 is not a valid boundary. Introduce BNDRY_MIN that deals with 0 values that mean no boundary. Notes: svn path=/head/; revision=285892
* Check the hw.proto.attach environment variable for devices thatMarcel Moolenaar2015-07-194-7/+70
| | | | | | | | | proto(4) should attach to instead of the normal driver. Document the variable. Notes: svn path=/head/; revision=285707
* Implement unload and sync operations.Marcel Moolenaar2015-07-032-0/+45
| | | | Notes: svn path=/head/; revision=285074
* Add create, destroy and load of memory descriptors.Marcel Moolenaar2015-07-034-18/+162
| | | | Notes: svn path=/head/; revision=285069
* Add an ISA/ACPI bus attachment to proto(4).Marcel Moolenaar2015-07-022-0/+130
| | | | Notes: svn path=/head/; revision=285058
* Change the probe to what was intended: attach to devices withMarcel Moolenaar2015-06-221-2/+1
| | | | | | | a type 0 header and not to function 0 devices. Notes: svn path=/head/; revision=284689
* We need to handle 64-bit BARs ourselves to avoid that theMarcel Moolenaar2015-06-121-8/+11
| | | | | | | | | | PCI infrastructure instantiates a non-existent resource. This has BARs suddenly show up with pciconf(8) under VMware as well. Now that we read the BAR ourselves, ask for the correct resource type. Notes: svn path=/head/; revision=284315
* Load the allocated memory and return both the physicalMarcel Moolenaar2015-06-102-4/+24
| | | | | | | address and the bus address to the application. Notes: svn path=/head/; revision=284246
* Implement mmap(2) for the busdma resource.Marcel Moolenaar2015-06-083-12/+39
| | | | Notes: svn path=/head/; revision=284168
* Add DMA memory allocation and freeing.Marcel Moolenaar2015-06-084-41/+181
| | | | | | | Slightly rework the tag handling. Notes: svn path=/head/; revision=284144
* DMA support part 1: DMA tag create & destroyMarcel Moolenaar2015-06-066-20/+293
| | | | | | | | | | Create a special resource (= device special file) for management of tags and maps, as well as for mapping memory into the address space. DMA resources are managed using the PROTO_IOC_BUSDMA ioctl. Part 1 implements tag creation, derivation and destruction. Notes: svn path=/head/; revision=284079
* Add proto(4): A driver for prototyping and diagnostics.Marcel Moolenaar2014-04-284-0/+602
It exposes I/O resources to user space, so that programs can peek and poke at the hardware. It does not itself have knowledge about the hardware device it attaches to. Sponsored by: Juniper Networks, Inc. Notes: svn path=/head/; revision=265055