Android4.0 analysis of the driver layer for USB mounting to the kernel (III)

Next, Chapter 4 Analysis of the process for attaching the kernel driver layer to android4.0 USB (II)
1. android_bind

Static int android_bind (struct usb_composite_dev * cdev) {struct android_dev * Dev = _ android_dev; // analyze the process of mounting the kernel driver layer to android4.0 USB (1 ), in the static int _ init Init (void) function, _ android_dev = dev; _ android_dev is a static struct usb_gadget * gadget = cdev-> gadget; intgcnum, ID, RET; usb_gadget_disconnect (gadget); // before initialization, ensure that the RET is disconnected = android_init_functions (Dev-> Functions, cdev); // The functions here are functions including mass_storage_function.. Next, analyze if (RET) return ret;/* allocate string descriptor numbers... note that string * contents can be overridden by the composite_dev glue. */id = usb_string_id (cdev); // enter the IF (ID <0) return ID by reading the device ID; strings_dev [string_manufacturer_idx]. id = ID; device_desc.imanufacturer = ID; id = usb_string_id (cdev); If (ID <0) return ID; strings_dev [string_product_idx]. id = ID; device_desc.iproduct = ID;/* DEFA Ult strings-shoshould be updated by userspace */strlcpy (manufacturer_string, "android", sizeof (manufacturer_string)-1); // fill in the default manufacturer and product information, it means that strlcpy (product_string, "android", sizeof (product_string)-1) can be changed through the upper layer; # ifdef config_javaswei_kernel // analyzes the Huawei kernel, so there is such a macro definition if (0! = Usb_para_data.usb_para.usb_serial [0]) {/* use Bluetooth address as USB serial number */strlcpy (serial_string, usb_para_data.usb_para.usb_serial, app_usb_serial_len ); // Huawei means using the Bluetooth address as the serial number} else {strlcpy (serial_string, usb_default_sn, sizeof (serial_string)-1 ); // If the Bluetooth address is 0, use the default serial number 012345789ab. The following figure shows bulabulabula... /* If the usb_serial is null and the Nv value is Google index, init. C will se T * the ports to factory mode. So update the variable to keep consistent. */If (google_index = usb_para_data.usb_para.usb_pid_index) // Google mode, 25! {Usb_pr ("% s USB serial number is null in Google mode. so switch to original mode \ n ", _ FUNC _); functions = ori_index; }}# elsestrlcpy (serial_string," 0123456789 abcdef ", sizeof (serial_string)-1 ); // Well, the default value is # endif/* config_javaswei_kernel */id = usb_string_id (cdev); If (ID <0) return ID; strings_dev [string_serial_idx] For the 0123456789abcdef serial number id = ID; device_desc.iserialnumber = ID;/* Backup the serial str id */# ifdef config_incluwei_kernel serial_str_id = ID; # endif/* config_incluwei_kernel */gcnum = require (gadget ); // identify the control chip and return a BCD value if (gcnum> = 0) device_desc.bcddevice = cpu_to_le16 (0x0200 + gcnum ); else {/* gadget zero is so simple (for now, no altsettings) That * It shocould not have problems with bulk-capable hardware. * So just warn about unrcognized controllers -- don't panic. ** things like configuration and altsetting numbering * can need hardware-specific attention though. */pr_warning ("% s: controller '% s' not recognized \ n", longname, Gadget-> name); device_desc.bcddevice = _ constant_cpu_to_le16 (0x9999 );} usb_gadget_set_selfpowered (gadget); // if the return error is not displayed on the front side, Dev-> cdev = cdev; return 0;} can be properly powered ;}

2. android_init_function

Static int functions (struct android_usb_function ** functions, struct functions * cdev) {struct android_dev * Dev = _ android_dev; struct functions * F; struct device_attribute ** attrs; struct device_attribute * ATTR; int err = 0; int Index = 0; For (; (F = * functions ++); index ++) {f-> dev_name = kasprintf (gfp_kernel, "F _ % s", F-> name); // For mass_storage_function, dev_name is f_mass_s Torage F-> Dev = device_create (android_class, Dev-> Dev, mkdev (0, index), F, F-> dev_name ); // create a device if (is_err (F-> Dev) {pr_err ("% s: failed to create Dev % s", _ FUNC __, F-> dev_name ); err = ptr_err (F-> Dev); goto err_create;} If (F-> init) {// F-> init points to mass_storage_function_init, so it is run at this time. Err = f-> Init (F, cdev); If (ERR) {pr_err ("% s: failed to init % s", _ FUNC __, f-> name); goto err_out;} attrs = f-> attributes; If (attrs) {While (ATTR = * attrs ++ )&&! Err) Err = device_create_file (F-> Dev, ATTR);} If (ERR) {pr_err ("% s: failed to create function % s attributes" ,__ func __, f-> name); goto err_out;} return 0; err_out: device_destroy (android_class, F-> Dev-> devt); err_create: kfree (F-> dev_name ); return err ;}

3. Summary

Because I am not very familiar with the kernel, I am not very familiar with the analysis in some places, but as a driver user and adapter, as the university teacher said, I don't have to know how to come, just know how to use it. Therefore, after analyzing the USB Mount-related kernel drivers, it is obvious that the most important thing is the parameter configuration process in the mass_storage_function_init function. determine the number of Luns and their respective attributes. Then the initialization can be completed in the kernel structure, and the rest is the processing related to vold.
For mounting, the first step is by init. RC creates a file named vold. fstab is linked, and then you only need to provide the correct parameters (or the default) to vold, and then configure storage_list.xml In the overlay of the framework, then you can achieve no problem with USB mounting.

** There may be some errors in analysis. If you have any experts passing by, I 'd like to give you some advice!