src/sys/modules/ahci, branch main FreeBSD source tree Remove residual blank line at start of Makefile 2024-07-15T22:43:39+00:00 Warner Losh imp@FreeBSD.org 2024-07-15T04:46:32+00:00 e9ac41698b2f322d55ccf9da50a3596edb2c1800 This is a residual of the $FreeBSD$ removal. MFC After: 3 days (though I'll just run the command on the branches) Sponsored by: Netflix 
This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix
sys: Remove $FreeBSD$: one-line sh pattern 2023-08-16T17:54:58+00:00 Warner Losh imp@FreeBSD.org 2023-08-16T17:54:58+00:00 031beb4e239bfce798af17f5fe8dba8bcaf13d99 Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/ 
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
sys/modules: normalize .CURDIR-relative paths to SRCTOP 2017-03-04T10:10:17+00:00 Enji Cooper ngie@FreeBSD.org 2017-03-04T10:10:17+00:00 193d9e768ba63fcfb187cfd17f461f7d41345048 This simplifies make output/logic Tested with: `cd sys/modules; make ALL_MODULES=` on amd64 MFC after: 1 month Sponsored by: Dell EMC Isilon 
This simplifies make output/logic

Tested with:	`cd sys/modules; make ALL_MODULES=` on amd64
MFC after:	1 month
Sponsored by:	Dell EMC Isilon
Add acpi_if.h to SRCS so we have it when building ahci_generic.c with ACPI. 2017-01-10T13:36:33+00:00 Andrew Turner andrew@FreeBSD.org 2017-01-10T13:36:33+00:00 ce790c9008056b4198d987269bdb52170dc86231 Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation 
Obtained from:	ABT Systems Ltd
Sponsored by:	The FreeBSD Foundation
ahci_generic.c needs ofw_bus_if.h, add it to the module. 2015-12-08T20:05:27+00:00 Andrew Turner andrew@FreeBSD.org 2015-12-08T20:05:27+00:00 17d6a39aa7458d5ba7a481d1198b73fa62f4e95f 






Add ahci_generic to the ahci module on arm64.
2015-12-04T13:32:00+00:00

Andrew Turner
andrew@FreeBSD.org

2015-12-04T13:32:00+00:00

61d1f7f291698d3c42840222b776a36ac4597299

Pointed out by:	kib





Pointed out by:	kib







Separate out PCI attachment from the main AHCI driver. Move checks of
2014-09-04T22:22:53+00:00

Warner Losh
imp@FreeBSD.org

2014-09-04T22:22:53+00:00

802df3ace64925cb23b020c9cf9b06118b7b7d5d

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





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







Refactor enclosure manegement support in ahci(4). Move it out into separate
2012-07-26T13:44:48+00:00

Alexander Motin
mav@FreeBSD.org

2012-07-26T13:44:48+00:00

d19f06b32434ccf7a7c4ff13a6da43f7782bef6d

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.





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.







Separate the parallel scsi knowledge out of the core of the XPT, and
2009-07-10T08:18:08+00:00

Scott Long
scottl@FreeBSD.org

2009-07-10T08:18:08+00:00

52c9ce25d8339ad0228be8aaf0e44b45314b38dc

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





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