struct driver_info
 

Hi,

while going through the usb drivers chapter in 'Linux device drivers' book, I came through the code which we use to match device to a driver. A structure 'driver_info' was described as well. It is not well documented about the usage of this structure. Can you guys let me know its usage with an example?

Thanks,

I am not familiar with this part of the book, but I think I have a pretty good guess as to what you are asking and will try to answer.

Each (registered or certified) USB device vendor has a "vendor ID" and each device that they manufacture has a "Device ID". These ID's are part of the data that is communicated during device enumeration. In addition, information regarding the end points, types of transfers supported, protocols, etc, will also be discovered. The structure most likely maps some or all of this information into a table that is indexed by the device and vendor ID numbers. By knowing the device and vendor ID, you can also record if there are any "quirks" associated with the device and program around them. Unfortunately, many manufacturer's don't fully comply with the standards and as long as it works with Window's they don't care. This means that in order to be supported in Linux, a work around for these non-compliance issues may be required.

Hi Noway2,

Thanks a lot. But still some doubts about the 'quirks' part. Can you give me an example to get a hold on that.

Thanks again,

Yes, I can. A few years back, as part of a larger project we developed a USB host controller using the NXP-1161A OTG controller that was developed on a TI DSP. We borrowed from the 1161A drivers that we were found for the Linux kernel (http://www.beyondlogic.org/usb/otghost.htm for reference). The purpose of the application was to be able to read UBS memory sticks and data log our application to them. In addition to borrowing from Linux, we read the specs on the SCSI command set, bulk-only-transport protocols, FAT-32 specification, etc. In other words we followed the standards.

Towards the end, we were testing with several different brands of USB sticks and USB external HDDs (which have the same command set). This by the way is an example of where the structure could come into play, if for example the device supports both the SCSI and ATAPI command sets on different endpoints. Anyway, we discovered a couple of the devices would enumerate, but would not mount as a disk.

It turns out that as part of the FAT decode you need to do several computations involving things like the number of sectors in order to be able to get the information needed to access the disk. After several days of head scratching, we came across an article (I think it may have been on LVR.com) that said that many vendors erroneously represent (I think it is the sector count) as being off by 1. When we adjusted this count per the article, the device worked perfectly. We still had a device that was an old 16Mb stick that I got at CompUSA that was made by Poinchips that would not work with our system and would only work with Windows.

So, in this case, we needed to hard code a work around into the software that it try this fix. We could use the vendor and device IDs as flags indicating that we needed to adjust the count. In our case it was simple to try the adjusted count if we received an error, but in a case like Windows or Linux where you have to support thousands of different devices, a table of the corrections could be immensely helpful.

Hi Noway2,

Thank you very much. Even though, I didnt get it completely, you reply, certainly started to make sense about the structure. Will work more on this.

Thank you verrrrrrrrrry much.

I feel really happy , when I see people taking great pains to solve others problem. I appreciate your reply very much.

Thanks,