aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/mca
Commit message (Collapse)AuthorAgeFilesLines
* Remove Micro Channel Architecture support. Of the commonly availableWarner Losh2017-02-153-687/+0
| | | | | | | | | | | | | | machines, only a few 486 machines that used it, and those haven't had enough memory to run FreeBSD for quite some time (often limited to 16MB). Not to be confused with the Machine Check Architecture, which is still very much alive and used (and untouched by this commit). No Objection From: arch@ Notes: svn path=/head/; revision=313783
* Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.Justin Hibbits2016-03-181-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.Justin Hibbits2016-02-201-1/+1
| | | | | | | | | | | | | | This simplifies checking for default resource range for bus_alloc_resource(), and improves readability. This is part of, and related to, the migration of rman_res_t from u_long to uintmax_t. Discussed with: jhb Suggested by: marcel Notes: svn path=/head/; revision=295832
* Convert rman to use rman_res_t instead of u_longJustin Hibbits2016-01-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075 Notes: svn path=/head/; revision=294883
* - There's no need to overwrite the default device method with the defaultMarius Strobl2011-11-221-2/+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. Notes: svn path=/head/; revision=227843
* strict kobj signatures: fix assortment of bus_read_ivar implsAndriy Gapon2009-06-111-1/+1
| | | | | | | | Reviewed by: imp, current@ Approved by: jhb (mentor) Notes: svn path=/head/; revision=194020
* Change the functions to ANSI in those cases where it breaks promotionRoman Divacky2009-02-241-13/+4
| | | | | | | | | | | to int rule. See ISO C Standard: SS6.7.5.3:15. Approved by: kib (mentor) Reviewed by: warner Tested by: silence on -current Notes: svn path=/head/; revision=189004
* Use __FBSDID().David E. O'Brien2003-08-241-1/+3
| | | | | | | Also some minor style cleanups. Notes: svn path=/head/; revision=119418
* Deprecate machine/limits.h in favor of new sys/limits.h.Alexander Kabaev2003-04-291-1/+1
| | | | | | | | | | Change all in-tree consumers to include <sys/limits.h> Discussed on: standards@ Partially submitted by: Craig Rodrigues <rodrigc@attbi.com> Notes: svn path=/head/; revision=114216
* Argh, isa(4), eisa(4) and mca(4) now attach to legacy(4) instead ofJohn Baldwin2002-09-261-1/+1
| | | | | | | | | | nexus(4) in the case of machines w/o equivalent bridges on a PCI bus. Reported by: winter Pointy hat to: jhb Notes: svn path=/head/; revision=104015
* - Remove an unused write_ivars function that didn't do anything anyway.John Baldwin2001-01-191-7/+1
| | | | | | | | - Return NULL from mca_alloc_resource() instead of ENOENT if we are passed in an empty resource list. Notes: svn path=/head/; revision=71239
* Reduce code duplication by using the GET_RESOURCE_LIST bus method and relatedMatthew N. Dodd2000-11-281-52/+18
| | | | | | | | | | | generic resource_list management functions. I'll deal with the EISA bits later. Not objected to by: new-bus Notes: svn path=/head/; revision=69295
* Set the RF_SHAREABLE flage when we allocate an IRQ.Matthew N. Dodd2000-03-131-0/+4
| | | | Notes: svn path=/head/; revision=57980
* Implement BUS_{GET,SET,DELETE}_RESOURCE methods.Matthew N. Dodd2000-01-131-2/+44
| | | | Notes: svn path=/head/; revision=55890
* Remove the 'ivars' arguement to device_add_child() andMatthew N. Dodd1999-12-031-1/+3
| | | | | | | | | | | | | | | | | | | device_add_child_ordered(). 'ivars' may now be set using the device_set_ivars() function. This makes it easier for us to change how arbitrary data structures are associated with a device_t. Eventually we won't be modifying device_t to add additional pointers for ivars, softc data etc. Despite my best efforts I've probably forgotten something so let me know if this breaks anything. I've been running with this change for months and its been quite involved actually isolating all the changes from the rest of the local changes in my tree. Reviewed by: peter, dfr Notes: svn path=/head/; revision=54073
* resource_list_{alloc,release}() takes a struct resource_list * as itsMatthew N. Dodd1999-11-061-3/+4
| | | | | | | | | first arg. Reminded by: Andy Farkas <andyf@speednet.com.au> Notes: svn path=/head/; revision=52915
* - Restore correct operation of bt_mca.Matthew N. Dodd1999-10-091-2/+2
| | | | | | | | | | | - Work around a problem not yet solved in the tree (but solved in mine.) device_get_ivars() should never be cast to a struct resource_list * The solution, under review, involves the creation of a device_get_resource_list() function. More later. Notes: svn path=/head/; revision=52050
* device_get_ivars() called twice. Remove second call and assignment.Matthew N. Dodd1999-09-261-1/+0
| | | | | | | Noticed by: Peter Notes: svn path=/head/; revision=51678
* Rip out the nastiness I cribbed from the EISA bus code and actuallyMatthew N. Dodd1999-09-262-321/+77
| | | | | | | | | | implement the resource management code correctly, using approved interfaces. While I'm here, clean up a few things. Notes: svn path=/head/; revision=51674
* This is the rest of the MCA support; new_bus code to be exact.Matthew N. Dodd1999-09-033-0/+931
Should we ever find ourselves on an RS/6000 this code should work with few changes. Notes: svn path=/head/; revision=50825
generated by cgit v1.2.3 (git 2.25.1) at 2026-03-17 06:25:50 +0000