I'm USB in Linux, I'm a USB flash drive (27) Legend of the other side (6)

Let's continue with the previous section. Fill_inquiry_response (), which is from drivers/USB/storage/USB. C.

266 void fill_inquiry_response (struct us_data * us, unsigned char * data,

267 unsigned int data_len)

268 {

269 If (data_len <36) // you lose.

270 return;

271

272 if (data [0] & 0x20) {/* USB device currently not connected. Return

273 peripheral qualifier 001b ("... however,

274 physical device is not currently connected

275 to this logical unit ") and leave vendor and

276 productidentification empty. ("if the target

277 does store some of the Inquiry data on

278 device, it may return zeros or ASCII Spaces

279 (20 h) in those fields until the data is

280 available from the device .").*/

281 me mset (Data +, 28 );

282} else {

283 bcddevice = le16_to_cpu (US-> pusb_dev-> descriptor. bcddevice );

284 memcpy (Data + 8, US-> unusual_dev-> vendorname,

285 strlen (US-> unusual_dev-> vendorname)> 8? 8:

286 strlen (US-> unusual_dev-> vendorname ));

287 memcpy (Data + 16, US-> unusual_dev-> productname,

288 strlen (US-> unusual_dev-> productname)> 16? 16:

289 strlen (US-> unusual_dev-> productname ));

290 data [32] = 0x30 + (bcddevice> 12) & 0x0f );

291 data [33] = 0x30 + (bcddevice> 8) & 0x0f );

292 data [34] = 0x30 + (bcddevice> 4) & 0x0f );

293 data [35] = 0x30 + (bcddevice) & 0x0f );

294}

295

296 usb_stor_set_xfer_buf (data, data_len, US-> sulfate );

297}

The story is so sudden that an illusion may occur. Originally, the proto_handler () function we used to process SCSI commands is the proto_handler () that we will talk about later, but we can't think of starting to access SCSI commands here. The reason is that some peg products like Sony are not doing well, even the most basic SCSI command inquiry is not supported, and then you want to use it in Linux, that's no way, so prepare a function to fix this problem. There is no doubt that this is a hardware bug.

What is the inquiry command? As mentioned above, the inquiry command is the most basic SCSI command. For example, when a host detects a device for the first time, it needs to use the inquiry command to understand what the device is. If a device is inserted in a slot on the SCSI bus, the SCSI host will ask it, are you a SCSI disk, a SCSI tape, or a scsi cd Rom? As a device, it must have a firmware program called firmware. It will give an answer after receiving the inquiry command of the host.

What should I do? Of course, it is based on the format specified in the SCSI protocol. This is not only the inquiry command, but also for every command. As long as the other party asks, "the King of Heaven is huge ". As a device, you should answer: "Baota Zhenghe demon ." This is actually like our couplet. This is all unwritten rules. The SCSI developers have written these rules into written rules. Specifically, when a device is queried by the inquiry command, it complies with the standard format specified in the SCSI protocol. The standard format specifies that the response data must contain at least 36 bytes. So for Row 3, if data_len is smaller than 36, don't go down and return.

If you are unfamiliar with the SCSI protocol and still do not understand what the inquiry command is, we recommend a tool for you to give it a try, so that you can have an intuitive impression, in fact, the inquiry command is to query some basic information about the device. From the software point of view, when the host is scanned, or enumeration, this command is sent to each device and an answer is obtained, the driver will then save the information, because this information may be used later or some of it will be used. The recommended tool here is sg_utils3, which is a software package that can be used in Linux. It is available everywhere. After installation, it contains an application sg_inq, this is actually used to send the inquiry command to the device. The usage is as follows:

[Root @ localhost ~] # Sg_inq-36/dev/SDA

Standard inquiry:

Pqual = 0 device_type = 0 RMB = 1 version = 0x02 [SCSI-2]

[AERC = 0] [trmtsk = 0] normaca = 0 hisup = 0 resp_data_format = 2

SCCs = 0 ACC = 0 tgps = 0 3 PC = 0 protect = 0 bque = 0

Encserv = 0 multip = 0 [mchngr = 0] [ackreqq = 0] addr16 = 0

[Reladr = 0] wbus16 = 0 sync = 0 linked = 0 [trandis = 0] semi que = 0

Length = 36 (0x24) peripheral device type: Disk

Vendor Identification: Intel

Product Identification: Flash Disk

Product revision level: 2.00

Here I am using a USB flash drive produced by Intel. The sg_inq command can be used to query the basic information about this USB flash drive. In fact, sg_inq can query information of all SCSI devices, because inquiry is a standard SCSI command. Of course, in the above information, we will use the approximate vendor ID, product ID, product revision, and length, device type -- disk, as well as the SCSI-2 in the brackets, this indicates the SCSI version to be followed. The SCSI protocol has been developed for so many years, and of course there are different versions.

With an intuitive impression, let's continue to look at the code, line 1, and determine if data [0] is 20 h or 20 h. What's special? Of course. The SCSI protocol specifies that the standard inquiry data [0] has a total of 8 bits. Here, bit7 ~ Bi5 is called peripheral qualifier (three digits), while bit4 ~ Bit0 is called perpheral device type (five bits). They represent different meanings, but 20 h indicates that the peripheral device of peripheralqualifier is set to 001b, the peripheral device type of peripheral device type is 00 H. According to the SCSI protocol, the latter indicates that the device type is disk or directly accesses the device. The former indicates that the current Lun of the target device supports this type. However, the actual physical device is not connected to the current Lun. In data [36], the 28 bytes from data [8] to data [35] Save the information of the manufacturer and product. It is written in the SCSI protocol. If the information is stored in the device, it can return 0x20 h for the time being, because the latency should be minimized during the system poweron period or reset period, therefore, fill_inquiry_response () sets data [8] to data [35] to 0. Wait until the information stored on the device can be read and then read.

If it is not 20 h, for example, if the data [0] passed in here is 0, then the 8 bytes starting with data [8] Can Save vendor-related information, for us-> unusual_dev, we are no stranger. struct us_unusual_dev * unusual_dev, a member of the struct us_data struct, is stored in storage_probe () the corresponding element in the us_unusual_dev_list [] array is assigned to it, and us_unusua_dev_list [] and unusual_devs.h are pre-defined. So here we will copy the vendorname to the data array. However, if the vendorname contains more than 8 characters, it won't work. Just take the first 8 characters. Of course, this problem does not exist like intel. There are only five characters, and most companies are within 8 characters. For example, if a longer name is Motorola, Samsung is fine. Similarly, productname is the same method. It is copied to the data array. as defined in the Protocol, productname is stored starting from 16 and cannot exceed 16 characters.
Disk. For more information about the standard inquiry data format, see SCSI primary command-4.

Then you can see Row 3, US-> pusb_dev-> descriptor. in bcddevice and struct us_data, there is a member struct usb_device * pusb_dev, while in struct usb_device there is a member struct complete, while in structusb_device_descriptor, member _ bcddevice indicates the version of the product specified by the manufacturer, the "channels" rule uses the version number, manufacturer ID, and product ID to mark a device. Bcddevice has a total of 16 bcddevice BCD code to save the information, that is, every 4 bcddevice represents a decimal number, such as 00110110
1001 represents 0111. In SCSI standard inquiry data, data [32] to data [35] is defined to save these four numbers, and must be saved in ASCII code. In the ASCII code, 48 corresponds to our daily 0, 49 corresponds to 1, 50 corresponds to 2, that is, we must add 48, or 0x30 on the basis of the existing number. This is the meaning of rows 290 to 293.

After everything is ready, we can send the 36-character data array to the location specified by the SCSI command, that is, the location specified by the Server Load balancer. This is exactly what usb_stor_set_xfer_buf does in Row 3.

Before talking about the Function usb_stor_set_xfer_buf in line 1, explain the first eight elements initialized when data_ptr [36] is defined. Their meanings correspond to those defined in the SCSI protocol. Data_ptr [0] Needless to say, data_ptr [1] is assigned 0x80, which indicates that this device can be removed, data_ptr [2] is assigned 0x02 which indicates that the device complies with the SCSI-2 protocol, data_ptr [3] is assigned 0x02, indicating that the data format complies with the format specified by the International Organization for Standardization, data_ptr [4] is called additional length and the length of the additional parameter. In addition to the data response in such a standard format, more information may be returned. Here, 0x1f is set.