I am USB in Linux, I am a USB flash drive (19). Will it be far away in spring? (5)

After reading get_transport (), continue to read the get_protocol () and get_pipes () functions. Still from drivers/USB/storage/USB. C:

672 static int get_protocol (struct us_data * US)

673 {

674 switch (US-> subclass ){

675 caseus_ SC _rbc:

676 US-> protocol_name = "Reduced block commands (RBC )";

677 US-> proto_handler = usb_stor_transparent_scsi_command;

678 break;

679

680 case us_ SC _8020:

681 US-> protocol_name = "8020i ";

682 US-> proto_handler = usb_stor_atapi_command;

683 US-> max_lun = 0;

684 break;

685

686 caseus_ SC _qic:

687 US-> protocol_name = "QIC-157 ";

688 US-> proto_handler = usb_stor_qic157_command;

689 US-> max_lun = 0;

690 break;

691

692 caseus_ SC _8070:

693 US-> protocol_name = "8070i ";

694 US-> proto_handler = usb_stor_atapi_command;

695 US-> max_lun = 0;

696 break;

697

698 caseus_ SC _scsi:

699 US-> protocol_name = "transparent SCSI ";

700 US-> proto_handler = usb_stor_transparent_scsi_command;

701 break;

702

703 caseus_ SC _ufi:

704 US-> protocol_name = "Uniform floppy interface (UFI )";

705 US-> proto_handler = usb_stor_ufi_command;

706 break;

707

708 # ifdef config_usb_storage_isd200

709 case us_ SC _isd200:

710 US-> protocol_name = "isd200 ATA/atapi ";

711 US-> proto_handler = isd200_ata_command;

712 break;

713 # endif

714

Default 715:

716 return-EIO;

717}

718 us_debugp ("Protocol: % s \ n", US-> protocol_name );

719 return 0;

720}

This code is easy to understand. It is determined by us-> subclass. For a USB flash drive, spec specifies that its subclass is us_ SC _scsi, so here is two assignment statements: one is to make us protocol_name "transparent SCSI ", the other is to set us proto_handler to usb_stor_transparent_scsi_command, which is a function pointer.

Then get_pipes (), from drivers/USB/storage/USB. C:

723 static int get_pipes (struct us_data * US)

724 {

725 structusb_host_interface * altsetting =

726 US-> pusb_intf-> cur_altsetting;

727 int I;

728 struct usb_endpoint_descriptor * EP;

729 struct usb_endpoint_descriptor * ep_in = NULL;

730 struct usb_endpoint_descriptor * ep_out = NULL;

731 structusb_endpoint_descriptor * ep_int = NULL;

732

733 /*

734 * Find the first endpoint of each type we need.

735 * We are expecting a minimum of 2 endpoints-in and out (bulk ).

736 * an optional interrupt-in is OK (necessary for CBI protocol ).

737 * We will ignore any others.

738 */

739 for (I = 0; I <altsetting-> DESC. bnumendpoints; I ++ ){

740 Ep = & altsetting-> endpoint [I]. DESC;

741

742 if (usb_endpoint_xfer_bulk (EP )){

743 if (usb_endpoint_dir_in (EP )){

744 if (! Ep_in)

745 ep_in = EP;

746} else {

747 if (! Ep_out)

748 ep_out = EP;

749}

750}

751

752 else if (usb_endpoint_is_int_in (EP )){

753 if (! Ep_int)

754 ep_int = EP;

755}

756}

757

758 if (! Ep_in |! Ep_out | (US-> protocol = us_pr_cbi &&! Ep_int )){

759 us_debugp ("endpoint sanity check failed! Rejectingdev. \ n ");

760 return-EIO;

761}

762

763/* calculate and store the pipevalues */

764 us> send_ctrl_pipe = usb_sndctrlpipe (US-> pusb_dev, 0 );

765 US-> recv_ctrl_pipe = usb_rcvctrlpipe (US-> pusb_dev, 0 );

766 US-> send_bulk_pipe = usb_sndbulkpipe (US-> pusb_dev,

767 ep_out-> bendpointaddress & usb_endpoint_number_mask );

768 US-> recv_bulk_pipe = usb_rcvbulkpipe (US-> pusb_dev,

769 ep_in-> bendpointaddress & usb_endpoint_number_mask );

770 if (ep_int ){

771 US-> recv_intr_pipe = usb_rcvintpipe (US-> pusb_dev,

772 ep_int-> bendpointaddress & usb_endpoint_number_mask );

773 US-> ep_binterval = ep_int-> binterval;

774}

775 return 0;

776}

This function can be said to be a complicated one. Please let me give you a try.

Row 3, US-> pusb_intf. Remember the value assigned in associate_dev. If you do not remember it, check it again. That's right, us-> pusb_intf is the interface (pointer) that we mentioned most often in our story ). Its member cur_altsetting is the current setting. I have also encountered this problem when talking about associate_dev. It is a struct pointer of structusb_host_interface. Now we use another pointer to temporarily replace altsetting. Next we will use its members DESC and endpoint.

Looking back at structusb_host_interface, we can see its two members: struct usb_interface_descriptor DESC and struct usb_host_endpoint * endpoint. Among them, DESC is needless to say, it is the interface descriptor of this interface, and the endpoint pointer records several endpoints, they are stored in the form of an array, and the endpoint points to the array header. These are all set during USB core enumeration. We don't need to worry about them, just use them. The definition of struct usb_host_endpoint is provided here, from include/Linux/USB. h:

59 struct usb_host_endpoint {

60 structusb_endpoint_descriptor DESC;

61 structlist_head urb_list;

62 void * hcpriv;

63 struct ep_device * ep_dev;/* For sysfs info */

64

65 unsigned char * extra;/* extra descriptors */

66 intextralen;

67 };

Then we define several struct pointers of struct usb_endpoint_descriptor. As the name suggests, this is the descriptor of the corresponding endpoint. The definition is from include/Linux/USB/ch9.h:

312/* usb_dt_endpoint: endpoint descriptor */

313 struct usb_endpoint_descriptor {

314 _ u8 blength;

315 _ u8 bdescriptortype;

316

317 _ u8 bendpointaddress;

318 _ u8 bmattributes;

319 _ le16wmaxpacketsize;

320 _ u8 binterval;

321

322/* Note: These two are _ only _ in audio endpoints .*/

323/* use usb_dt_endpoint * _ SIZE inblength, not sizeof .*/

324 _ u8 brefresh;

325 _ u8 bsynchaddress;

326} _ attribute _ (packed ));

So far, the four descriptors are made one by one. Before proceeding, let's make a conclusion: What is a descriptor? Each USB device has four descriptors. Here we use a USB flash drive as an example. Have you heard of flash memory? Intel, Samsung, these are flash memory, of course, usually referred to as flash. What role does flash play in a USB flash disk? Flash is used to store data for users, and Flash in a USB flash disk is equivalent to a hard disk in a PC, which stores data mainly. In addition to storing data for users, the device also needs to store some inherent information of the device itself. For example, who is the last name of the device? Who produced it? There is still some information. For example, the device has several configurations, several interfaces, and many other features.

In this world, apart from flashmemory, there is also an object called EEPROM, which is also used for storage. It is the predecessor of EEPROM, flash is a low-cost ROM product developed based on the eeprom technology.

The same as flash, the eeprom requires an electrical erasure, but the EEPROM can be erased in bytes, unlike flash, in this way, it is convenient to use the eeprom only when few data changes are required. Therefore, this feature of EEPROM makes its circuit more complex and the integration is not high. One Bit requires two tubes: one to store the charge information and the other to act as the switch. Therefore, the cost of EEPROM is high. Flash simplifies some circuits and reduces the cost a lot.

Therefore, the USB device usually has a flash chip and an EEPROM chip. Flash is used to store data for customers, while EEPROM is used to store information of devices. This is why when Intel sells flash chips to Motorola, the mobile phone manufacturer we see is Motorola rather than intel, because although we wrote our vendor ID in flash, however, for the final finished products, the provided information is from the EEPROM, so when you connect the USB device to the computer through the USB interface, if the computer can display the manufacturer, so it must be the final packaging manufacturer, rather than the flash manufacturer. What is written in the eeprom? In what format? This is exactly what USB
According to spec, this format is the descriptor format. Device descriptors, configuration descriptors, interface descriptors, endpoint descriptors, and other device-specific descriptors of certain categories, such as hub descriptors, are very standard, in particular, each USB device supports these four standard descriptors. Therefore, the USB core layer can read them with the same code, instead of letting our device drivers read them by themselves. This is the benefit of centralized power, everything everyone has to do is simply let the above-mentioned items be done together.

Rows from 739 to 756 are in a loop. bnumendpoints is a member of the interface descriptor, indicating the number of endpoints of this interface. However, this does not include endpoint 0, endpoint 0 must be provided by any USB device. This endpoint is used for control transmission, that is, it is a control endpoint. Because of this, even if a device does not have any settings, the USB host can start to communicate with it, even if it does not know other endpoints, but at least know that it must have a zero-number endpoint, or a control endpoint.

In addition, USB Mass Storage usually has two batch endpoints for batch transmission, that is, batch transmission. We read and write files in the USB flash drive in batches. Therefore, there is no doubt that for the mass storage device, batch transmission is its main way of working. The principle is very simple. We use a USB flash disk to read and write files. Dealing with these descriptors is nothing more than helping us ultimately achieve file read and write, which is the true mission of every USB storage device.

So let's take a look at what the loop is doing. altsetting-> endpoint [I]. DESC, we can see from the definition of the struct usb_host_endpoint, that is, DESC is a variable of struct usb_endpoint_descriptor. We have just defined four pointers for such struct: EP, ep_in, ep_out, and ep_int. It is very simple. It is used to record the endpoint descriptor. ep_in is used to bulk-in, and ep_out is used to bulk-out, ep_int is used to record the interrupt endpoint (if any ). While EP is just a temporary pointer.

Let's take a look at structusb_endpoint_descriptor. In its members, bmattributes represents an attribute with a total of eight bits. bit1 and bit0 are collectively referred to as transfer type, that is, transmission type, 00 indicates control, 01 indicates, and so on, 10 indicates batch processing, and 11 indicates interruption. Therefore, by comparing these Members, you can determine the transmission type of the endpoint. This function usb_endpoint_xfer_bulk () is defined in include/Linux/USB. h:

571 static inline int usb_endpoint_xfer_bulk (conststruct usb_endpoint _ descriptor * EPD)

572 {

573 return (EPD-> bmattributes & usb_endpoint_xfertype_mask) =

574 usb_endpoint_xfer_bulk );

575}

The macro usb_endpoint_xfertype_mask is defined in include/Linux/USB/ch9.h:

338 # define usb_endpoint_xfertype_mask 0x03/* In bmattributes */

339 # define usb_endpoint_xfer_control 0

340 # define usb_endpoint_xfer_isoc 1

341 # define usb_endpoint_xfer_bulk 2

342 # define usb_endpoint_xfer_int 3

From the preceding annotations, we can see that row 742 is used to determine whether the description of this endpoint descriptor is a batch endpoint. If yes, continue the comparison. Let's first look at bendpointaddress. Another member of this struct usb_endpoint_descriptor is also eight bits, or one byte. bit7 indicates the direction of this endpoint, 0 indicates out, and 1 indicates in. The out and in are for the host, the out is from the host to the device, and the in is from the device to the host. Therefore, you can compare this member to determine the direction of the endpoint. The function usb_endpoint_dir_in () for this task also comes from include/Linux/USB. h:

549 static inline int usb_endpoint_dir_in (conststruct usb_endpoint _ descriptor * EPD)

550 {

551 return (EPD-> bendpointaddress & usb_endpoint_dir_mask) = usb_dir_in );

552}

Macro usb_dir_in and usb_endpoint_dir_mask are still from include/Linux/usb_ch9.h:

48 # define usb_dir_out 0/* To device */

49 # define usb_dir_in 0x80/* to host */

336 # define usb_endpoint_dir_mask 0x80

Therefore, it is obvious to point ep_in and ep_out to the specified endpoint descriptor.

In the next row, usb_endpoint_is_int_in () comes from include/Linux/USB. h:

646 static inline int usb_endpoint_is_int_in (conststruct usb_endpoint _ descriptor * EPD)

647 {

648 return (usb_endpoint_xfer_int (EPD) & usb_endpoint_dir_in (EPD ));

649}

With the above two functions as the basis, this function will no longer need to be mentioned. In short, the else if function in row 752 is to let the ep_int point to the interrupt endpoint if the endpoint is the interrupt endpoint. We have said that each type of USB device has an uncertain number of endpoints on it and must comply with the specifications of such devices. The USB Mass Storage specification specifies that, a usb mass storage device must have at least two bulk endpoints, which are obviously required. Undoubtedly, there may be an interrupt endpoint, which supports the CBI protocol, that is, the control/bulk/interrupt protocol. We have also said that the USB flash drive complies with the bulk-only protocol and does not require an interrupt endpoint.

There is nothing to say about the code from lines 758 to lines 761. It is unreasonable to determine whether ep_in or ep_out exists, or whether it complies with the CBI protocol but does not interrupt the endpoint. Of course, errors will occur!

There is a small piece of code left. Let's look at it in the next section. It should be said that after this function is completed, we will start the most exciting part. It is the great usb_stor_acquire_resources (). Darkness is approaching, and Dawn has taken us on the road. Let's look forward to it together. At the same time, let's make a summary. Previously we spent a lot of space to pave the way for usb_stor_acquire_resources (). let's review what it did?

First, we start from storage_probe and call a total of five functions, which are assocaite_dev, get_device_info, get_transport, get_protocol, and get_pipes. What is our purpose? It is very simple to build a data structure. It is the legendary struct us_data, and its name is us. We have built it, applied for memory for it, and assigned values to its elements, so that we can make good use of it in the future.

These five functions are not difficult, and you must write them. What's hard is how to define struct us_data. Don't forget that this data structure was designed by code writers for the USB-storage module. The so-called programming is nothing more than adding algorithms to the data structure. That's right. This is defined in drivers/USB/storage/USB. the data structure in H is up to 60 rows. We still haven't met many of her members, but don't worry. We will see it later. Well, although get_pipes has not been mentioned for a short time, we can say goodbye to the five functions in advance. XI Murong said that if we have to separate them, we should say goodbye, I also want to save a thank you in my heart. Thank you for giving you a memory.