drivers/usb/storage/initializers.c
Source file repositories/reference/linux-study-clean/drivers/usb/storage/initializers.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/usb/storage/initializers.c- Extension
.c- Size
- 2841 bytes
- Lines
- 95
- Domain
- Driver Families
- Bucket
- drivers/usb
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/errno.husb.hinitializers.hdebug.htransport.h
Detected Declarations
function usb_stor_euscsi_initfunction usb_stor_ucr61s2b_initfunction usb_stor_huawei_e220_init
Annotated Snippet
// SPDX-License-Identifier: GPL-2.0+
/*
* Special Initializers for certain USB Mass Storage devices
*
* Current development and maintenance by:
* (c) 1999, 2000 Matthew Dharm (mdharm-usb@one-eyed-alien.net)
*
* This driver is based on the 'USB Mass Storage Class' document. This
* describes in detail the protocol used to communicate with such
* devices. Clearly, the designers had SCSI and ATAPI commands in
* mind when they created this document. The commands are all very
* similar to commands in the SCSI-II and ATAPI specifications.
*
* It is important to note that in a number of cases this class
* exhibits class-specific exemptions from the USB specification.
* Notably the usage of NAK, STALL and ACK differs from the norm, in
* that they are used to communicate wait, failed and OK on commands.
*
* Also, for certain devices, the interrupt endpoint is used to convey
* status of a command.
*/
#include <linux/errno.h>
#include "usb.h"
#include "initializers.h"
#include "debug.h"
#include "transport.h"
/*
* This places the Shuttle/SCM USB<->SCSI bridge devices in multi-target
* mode
*/
int usb_stor_euscsi_init(struct us_data *us)
{
int result;
usb_stor_dbg(us, "Attempting to init eUSCSI bridge...\n");
result = usb_stor_control_msg(us, us->send_ctrl_pipe,
0x0C, USB_RECIP_INTERFACE | USB_TYPE_VENDOR,
0x01, 0x0, NULL, 0x0, 5 * HZ);
usb_stor_dbg(us, "-- result is %d\n", result);
return 0;
}
/*
* This function is required to activate all four slots on the UCR-61S2B
* flash reader
*/
int usb_stor_ucr61s2b_init(struct us_data *us)
{
struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap*) us->iobuf;
struct bulk_cs_wrap *bcs = (struct bulk_cs_wrap*) us->iobuf;
int res;
unsigned int partial;
static const char init_string[] = "\xec\x0a\x06\x00$PCCHIPS";
usb_stor_dbg(us, "Sending UCR-61S2B initialization packet...\n");
bcb->Signature = cpu_to_le32(US_BULK_CB_SIGN);
bcb->Tag = 0;
bcb->DataTransferLength = cpu_to_le32(0);
bcb->Flags = bcb->Lun = 0;
bcb->Length = sizeof(init_string) - 1;
memset(bcb->CDB, 0, sizeof(bcb->CDB));
memcpy(bcb->CDB, init_string, sizeof(init_string) - 1);
res = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe, bcb,
US_BULK_CB_WRAP_LEN, &partial);
if (res)
return -EIO;
usb_stor_dbg(us, "Getting status packet...\n");
res = usb_stor_bulk_transfer_buf(us, us->recv_bulk_pipe, bcs,
US_BULK_CS_WRAP_LEN, &partial);
if (res)
return -EIO;
return 0;
}
/* This places the HUAWEI E220 devices in multi-port mode */
int usb_stor_huawei_e220_init(struct us_data *us)
{
int result;
result = usb_stor_control_msg(us, us->send_ctrl_pipe,
USB_REQ_SET_FEATURE,
USB_TYPE_STANDARD | USB_RECIP_DEVICE,
Annotation
- Immediate include surface: `linux/errno.h`, `usb.h`, `initializers.h`, `debug.h`, `transport.h`.
- Detected declarations: `function usb_stor_euscsi_init`, `function usb_stor_ucr61s2b_init`, `function usb_stor_huawei_e220_init`.
- Atlas domain: Driver Families / drivers/usb.
- Implementation status: source implementation candidate.
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.