proto: clean up empty lines in .c and .h files
Remove sparc64 kernel supportRemove all sparc64 specific filesRemove all sparc64 ifdefsRemovee indireeect sparc64 ifdefs
Lock busdma operations and serialize detach against open/closeUse sx to allow M_WAITOK allocations (suggested by markj).admbugs: 782Reviewed by: markj
proto: change device permissions to 0600C Turt reports that the driver is not thread safe and may haveexploitable races.Note that the proto device is intended for prototyping and development,an
proto: change device permissions to 0600C Turt reports that the driver is not thread safe and may haveexploitable 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 isinherently (and intentionally) insecure, but it might as well be limitedto root only.admbugs: 782Reported by: C Turt <[email protected]>MFC after: 3 daysSponsored by: The FreeBSD Foundation
show more ...
Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.On some architectures, u_long isn't large enough for resource definitions.Particularly, powerpc and arm allow 36-bit (or larger) physic
Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.On some architectures, u_long isn't large enough for resource definitions.Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, buttype `long' is only 32-bit. This extends rman's resources to uintmax_t. Withthis 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'spossible for uintmax_t to grow, it's highly unlikely it will become 128-bit on32-bit architectures. 64-bit architectures should have plenty of RAM to absorbthe increase on resource sizes if and when this occurs, and the number ofresources on memory-constrained systems should be sufficiently small as to notpose a drastic overhead. That being said, uintmax_t was chosen for sourceclarity. If it's specified as uint64_t, all printf()-like calls would eitherneed casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_taren't horrible, but it would also bake into the API forresource_list_print_type() either a hidden assumption that entries get cast touintmax_t for printing, or these calls would need the PRI*64 macros. Sincesource code is meant to be read more often than written, I chose the clearestpath of simply using uintmax_t.Tested on a PowerPC p5020-based board, which places all device resources in0xfxxxxxxxx, and has 8GB RAM.Regression tested on qemu-system-i386Regression 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: YesSponsored by: Alex Perez/Inertial ComputingDifferential Revision: https://reviews.freebsd.org/D4544
Check the sync operation.
o make sure the boundary is a power of 2, when not zero.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
o make sure the boundary is a power of 2, when not zero.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.
Check the hw.proto.attach environment variable for devices thatproto(4) should attach to instead of the normal driver.Document the variable.
Implement unload and sync operations.
Add create, destroy and load of memory descriptors.
Add an ISA/ACPI bus attachment to proto(4).
Change the probe to what was intended: attach to devices witha type 0 header and not to function 0 devices.
We need to handle 64-bit BARs ourselves to avoid that thePCI infrastructure instantiates a non-existent resource.This has BARs suddenly show up with pciconf(8) underVMware as well. Now that we re
We need to handle 64-bit BARs ourselves to avoid that thePCI infrastructure instantiates a non-existent resource.This has BARs suddenly show up with pciconf(8) underVMware as well. Now that we read the BAR ourselves, askfor the correct resource type.
Load the allocated memory and return both the physicaladdress and the bus address to the application.
Implement mmap(2) for the busdma resource.
Add DMA memory allocation and freeing.Slightly rework the tag handling.
DMA support part 1: DMA tag create & destroyCreate a special resource (= device special file) for managementof tags and maps, as well as for mapping memory into the addressspace. DMA resources ar
DMA support part 1: DMA tag create & destroyCreate a special resource (= device special file) for managementof tags and maps, as well as for mapping memory into the addressspace. DMA resources are managed using the PROTO_IOC_BUSDMA ioctl.Part 1 implements tag creation, derivation and destruction.
Add proto(4): A driver for prototyping and diagnostics.It exposes I/O resources to user space, so that programs can peekand poke at the hardware. It does not itself have knowledge aboutthe hardwar
Add proto(4): A driver for prototyping and diagnostics.It exposes I/O resources to user space, so that programs can peekand poke at the hardware. It does not itself have knowledge aboutthe hardware device it attaches to.Sponsored by: Juniper Networks, Inc.