133 * FMA capabilities of scsi_device.
134 */
135 int sd_fm_capable;
136
137 /*
138 * mdi_pathinfo_t pointer to pathinfo node for scsi_device structure
139 * allocated by the scsi_vhci for transport to a specific pHCI path.
140 */
141 void *sd_pathinfo;
142
143 /*
144 * sd_uninit_prevent - Counter that prevents demotion of
145 * DS_INITIALIZED node (esp loss of devi_addr) by causing
146 * DDI_CTLOPS_UNINITCHILD failure - devi_ref will not protect
147 * demotion of DS_INITIALIZED node.
148 *
149 * sd_tran_tgt_free_done - in some cases SCSA will call
150 * tran_tgt_free(9E) independent of devinfo node state, this means
151 * that uninitchild code should not call tran_tgt_free(9E).
152 */
153 int sd_uninit_prevent:16,
154 sd_tran_tgt_free_done:1,
155 sd_flags_pad:15;
156
157 /*
158 * The 'sd_tran_safe' field is a grotty hack that allows direct-access
159 * (non-scsa) drivers (like chs, ata, and mlx - which all make cmdk
160 * children) to *illegally* put their own vector in the scsi_address(9S)
161 * 'a_hba_tran' field. When all the drivers that overwrite
162 * 'a_hba_tran' are fixed, we can remove sd_tran_safe (and make
163 * scsi_hba.c code trust that the 'sd_address.a_hba_tran' established
164 * during initchild is still valid when uninitchild occurs).
165 *
166 * NOTE: This hack is also shows up in the DEVP_TO_TRAN implementation
167 * in scsi_confsubr.c.
168 *
169 * NOTE: The 'sd_tran_safe' field is only referenced by SCSA framework
170 * code, so always keeping it at the end of the scsi_device structure
171 * (until it can be removed) is OK. It use to be called 'sd_reserved'.
172 */
173 struct scsi_hba_tran *sd_tran_safe;
|
133 * FMA capabilities of scsi_device.
134 */
135 int sd_fm_capable;
136
137 /*
138 * mdi_pathinfo_t pointer to pathinfo node for scsi_device structure
139 * allocated by the scsi_vhci for transport to a specific pHCI path.
140 */
141 void *sd_pathinfo;
142
143 /*
144 * sd_uninit_prevent - Counter that prevents demotion of
145 * DS_INITIALIZED node (esp loss of devi_addr) by causing
146 * DDI_CTLOPS_UNINITCHILD failure - devi_ref will not protect
147 * demotion of DS_INITIALIZED node.
148 *
149 * sd_tran_tgt_free_done - in some cases SCSA will call
150 * tran_tgt_free(9E) independent of devinfo node state, this means
151 * that uninitchild code should not call tran_tgt_free(9E).
152 */
153 unsigned sd_uninit_prevent:16,
154 sd_tran_tgt_free_done:1,
155 sd_flags_pad:15;
156
157 /*
158 * The 'sd_tran_safe' field is a grotty hack that allows direct-access
159 * (non-scsa) drivers (like chs, ata, and mlx - which all make cmdk
160 * children) to *illegally* put their own vector in the scsi_address(9S)
161 * 'a_hba_tran' field. When all the drivers that overwrite
162 * 'a_hba_tran' are fixed, we can remove sd_tran_safe (and make
163 * scsi_hba.c code trust that the 'sd_address.a_hba_tran' established
164 * during initchild is still valid when uninitchild occurs).
165 *
166 * NOTE: This hack is also shows up in the DEVP_TO_TRAN implementation
167 * in scsi_confsubr.c.
168 *
169 * NOTE: The 'sd_tran_safe' field is only referenced by SCSA framework
170 * code, so always keeping it at the end of the scsi_device structure
171 * (until it can be removed) is OK. It use to be called 'sd_reserved'.
172 */
173 struct scsi_hba_tran *sd_tran_safe;
|