Documentation/scsi/libsas.rst
Source file repositories/reference/linux-study-clean/Documentation/scsi/libsas.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/scsi/libsas.rst- Extension
.rst- Size
- 13804 bytes
- Lines
- 459
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
struct my_phystruct my_sas_hastruct sas_taskfunction this
Annotated Snippet
struct my_phy {
blah;
struct sas_phy sas_phy;
bleh;
};
And then all the phys are an array of my_phy in your HA
struct (shown below).
Then as you go along and initialize your phys you also
initialize the sas_phy struct, along with your own
phy structure.
In general, the phys are managed by the LLDD and the ports
are managed by the SAS layer. So the phys are initialized
and updated by the LLDD and the ports are initialized and
updated by the SAS layer.
There is a scheme where the LLDD can RW certain fields,
and the SAS layer can only read such ones, and vice versa.
The idea is to avoid unnecessary locking.
enabled
- must be set (0/1)
id
- must be set [0,MAX_PHYS)]
class, proto, type, role, oob_mode, linkrate
- must be set
oob_mode
- you set this when OOB has finished and then notify
the SAS Layer.
sas_addr
- this normally points to an array holding the sas
address of the phy, possibly somewhere in your my_phy
struct.
attached_sas_addr
- set this when you (LLDD) receive an
IDENTIFY frame or a FIS frame, _before_ notifying the SAS
layer. The idea is that sometimes the LLDD may want to fake
or provide a different SAS address on that phy/port and this
allows it to do this. At best you should copy the sas
address from the IDENTIFY frame or maybe generate a SAS
address for SATA directly attached devices. The Discover
process may later change this.
frame_rcvd
- this is where you copy the IDENTIFY/FIS frame
when you get it; you lock, copy, set frame_rcvd_size and
unlock the lock, and then call the event. It is a pointer
since there's no way to know your hw frame size _exactly_,
so you define the actual array in your phy struct and let
this pointer point to it. You copy the frame from your
DMAable memory to that area holding the lock.
sas_prim
- this is where primitives go when they're
received. See sas.h. Grab the lock, set the primitive,
release the lock, notify.
port
- this points to the sas_port if the phy belongs
to a port -- the LLDD only reads this. It points to the
sas_port this phy is part of. Set by the SAS Layer.
ha
Annotation
- Detected declarations: `struct my_phy`, `struct my_sas_ha`, `struct sas_task`, `function this`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.