src - FreeBSD source tree

	Commit message (Collapse)	Author	Age	Files	Lines
*	sys/modules: normalize .CURDIR-relative paths to SRCTOP	Enji Cooper	2017-03-04	1	-1/+1
\| \| \| \| \| \| \| \| \| \| \|	This simplifies make output/logic Tested with: `cd sys/modules; make ALL_MODULES=` on amd64 MFC after: 1 month Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=314651
*	Add acpi_if.h to SRCS so we have it when building ahci_generic.c with ACPI.	Andrew Turner	2017-01-10	1	-1/+1
\| \| \| \| \| \| \| \|	Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=311875
*	ahci_generic.c needs ofw_bus_if.h, add it to the module.	Andrew Turner	2015-12-08	1	-1/+1
\| \| \| \|	Notes: svn path=/head/; revision=292001
*	Add ahci_generic to the ahci module on arm64.	Andrew Turner	2015-12-04	1	-0/+4
\| \| \| \| \| \| \|	Pointed out by: kib Notes: svn path=/head/; revision=291768
*	Separate out PCI attachment from the main AHCI driver. Move checks of	Warner Losh	2014-09-04	1	-1/+1
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	PCI IDs into quirks, which mostly fit (though you'd get no argument from me that AHCI_Q_SATA1_UNIT0 is oddly specific). Set these quirks in the PCI attachment. Make some shared functions public so that PCI and possibly other bus attachments can use them. The split isn't perfect yet, but it is functional. The split will be perfected as other bus attachments for AHCI are written. Sponsored by: Netflix Reviewed by: kan, mav Differential Revision: https://reviews.freebsd.org/D699 Notes: svn path=/head/; revision=271146
*	Refactor enclosure manegement support in ahci(4). Move it out into separate	Alexander Motin	2012-07-26	1	-1/+1
\| \| \| \| \| \| \| \| \| \| \| \|	subdevice ahciem. Emulate SEMB SES device from AHCI LED interface to expose it to users in form of ses(4) CAM device. If we ever see AHCI controllers supporting SES of SAF-TE over I2C as described by specification, they should fit well into this new picture. Sponsored by: iXsystems, Inc. Notes: svn path=/head/; revision=238805
*	Separate the parallel scsi knowledge out of the core of the XPT, and	Scott Long	2009-07-10	1	-0/+8
	modularize it so that new transports can be created. Add a transport for SATA Add a periph+protocol layer for ATA Add a driver for AHCI-compliant hardware. Add a maxio field to CAM so that drivers can advertise their max I/O capability. Modify various drivers so that they are insulated from the value of MAXPHYS. The new ATA/SATA code supports AHCI-compliant hardware, and will override the classic ATA driver if it is loaded as a module at boot time or compiled into the kernel. The stack now support NCQ (tagged queueing) for increased performance on modern SATA drives. It also supports port multipliers. ATA drives are accessed via 'ada' device nodes. ATAPI drives are accessed via 'cd' device nodes. They can all be enumerated and manipulated via camcontrol, just like SCSI drives. SCSI commands are not translated to their ATA equivalents; ATA native commands are used throughout the entire stack, including camcontrol. See the camcontrol manpage for further details. Testing this code may require that you update your fstab, and possibly modify your BIOS to enable AHCI functionality, if available. This code is very experimental at the moment. The userland ABI/API has changed, so applications will need to be recompiled. It may change further in the near future. The 'ada' device name may also change as more infrastructure is completed in this project. The goal is to eventually put all CAM busses and devices until newbus, allowing for interesting topology and management options. Few functional changes will be seen with existing SCSI/SAS/FC drivers, though the userland ABI has still changed. In the future, transports specific modules for SAS and FC may appear in order to better support the topologies and capabilities of these technologies. The modularization of CAM and the addition of the ATA/SATA modules is meant to break CAM out of the mold of being specific to SCSI, letting it grow to be a framework for arbitrary transports and protocols. It also allows drivers to be written to support discrete hardware without jeopardizing the stability of non-related hardware. While only an AHCI driver is provided now, a Silicon Image driver is also in the works. Drivers for ICH1-4, ICH5-6, PIIX, classic IDE, and any other hardware is possible and encouraged. Help with new transports is also encouraged. Submitted by: scottl, mav Approved by: re Notes: svn path=/head/; revision=195534